Do you think that filter is better where it was in compat.php because it's specifically about that right? compatibility with WP versions that don't support that variable yet.

Yup:

• if the plugin is active on a WP version that doesn't have this class => this will be loaded.
• if the plugin is active on a WP version that does have the class => this won't be loaded.

oh, but do we need to signal anywhere that this class shouldn't be loaded when the plugin requires WP 5.6? I'm not sure how that works.

one thing we could do would be to move this code from load.php:

if ( ! class_exists( 'WP_Block_Supports' ) ) {
	require_once dirname( __FILE__ ) . '/class-wp-block-supports.php';
}

to compat.php (and add the comment about WP 5.6).

What do you think?

One of the goals is to only set up the register_block_type_args filter when the WP_Block_Supports class loaded in the runtime is the one from the plugin and not core, correct? If so, what if the plugin's version of the class provided its own wp_block_supports_track_block_to_render as a static method? That way, we would have:

• Conditional class loading in load.php, as is the case for all other classes
• In compat.php, something like:

if ( class_exists( 'WP_Block_Supports' ) && method_exists( 'WP_Block_Supports', 'track_block_to_render' ) ) {
    add_filter( 'register_block_type_args', array( 'WP_Block_Support', 'track_block_to_render' ) );
}

Or am I missing something?

The advantages are that we preserve normal loading, and avoid any arbitrary signals to instead use duck-typing (i.e. merely requiring the method to exist in order to register it as a filter).

One of the goals is to only set up the register_block_type_args filter when the WP_Block_Supports class loaded in the runtime is the one from the plugin and not core, correct?

I would think this PR should also be ported to core for 5.6 as it is. Following that rationale my answer would be no.

Sure, there's the edge case of WP 5.6 beta 1, which already has a class different to this one. I'd argue that's a short-lived version for testing purposes, though. Anyway, the issue with inner blocks will be fixed anyway (because it's already fixed in core beta 1) and we don't need the current code in compat.php.

Fair enough. :)

Should we go ahead and merge this, then? I've already ported the changes to WordPress/wordpress-develop#640 Would benefit from some orientation as to how to land that one.